\documentclass{report}
\usepackage{amsmath}
\usepackage[french]{babel}
%\usepackage[latin1]{inputenc}
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage{setspace}
\usepackage{multicol}
\usepackage{verbatim}
\usepackage{amsfonts}
\usepackage{color}
\usepackage{listings}
\usepackage{mathtools}
\usepackage{amssymb}
\usepackage{comment}
%\usepackage{vmargin}





%\usepackage{subfigure}
%%%%%%%%%%%%%%%% Lengths %%%%%%%%%%%%%%%%
\setlength{\textwidth}{15.5cm}
\setlength{\evensidemargin}{0.7cm}
\setlength{\oddsidemargin}{0.7cm}

%%%%%%%%%%%%% Java Listings %%%%%%%%%%%%%
\definecolor{jbackground}{rgb}{0.85,0.85,0.85}
\lstset{language=Java, backgroundcolor=\color{jbackground}}

%%%%%%%%%%%%%%%% Variables %%%%%%%%%%%%%%%%
\def\projet{6}
\def\titre{Exceptions}
\def\groupe{3}
\def\equipe{1}
\def\coordinator{apottier}
\def\others{youidani, osribti, felwahbi, mhaddoun}

\begin{document}
%\setlength{\topmargin}{-50pt}
%\setlength{\textheight}{758pt}
%\setlength{\textwidth}{17cm}
%\setlength{\evensidemargin}{-25pt}
%\setlength{\oddsidemargin}{-15pt}

%%%%%%%%%%%%%%%% Header %%%%%%%%%%%%%%%%
\noindent\begin{minipage}{0.98\textwidth}
  \vskip 0mm
  \noindent
  { \begin{tabular}{p{7.5cm}}
      {\bfseries \sffamily
        Project n\projet} \\ 
      {\itshape \titre}
    \end{tabular}}
  \hfill 
  \fbox{\begin{tabular}{l}
      {~\hfill \bfseries \sffamily Group n\groupe\ - Team n\equipe
        \hfill~} \\[2mm] 
      Coordinateur : \coordinator \\
      Membres d'équipe : \others
    \end{tabular}}
  \vskip 4mm ~

  ~~~\parbox{0.95\textwidth}{\small \textit{Résumé~:Dans cette partie nous nous intéressons à la gestion d'erreur en utilisant les méchanismes d'exceptions du langage java.} \sffamily
}
  \vskip 1mm ~
  
\end{minipage}

%\setstretch{2}
%%%%%%%%%%%%%%%% Main part %%%%%%%%%%%%%%%%

%%%%%%%%%%%%% partie 1 %%%%%%%%%%%%%%%%%%%%

\section*{Douzième itération}
En premier lieu  nous nous intéressons aux exceptions que l'on peut rencontrer dans l'instanciation des divers objets.
\subsection*{Lever une exception}
La manière la plus directe de réaliser ces classes est d'utiliser l'héritage, permettant comme vu dans le précédent TD
de factoriser le code et de faciliter la maintenance, et de redéfinir les deux méthodes abstraites. 
L'idée est de faire hériter les réalisations implémentant les différents types de passager et action à l'arrêt (ou caractère) de 
PassagerAbstrait ce qui stipule

%Combien faut-il construire de classes concrètes ?
La construction de 20 classes concrètes : en
effet, l'héritage multiple étant interdit, il faut créer autant de
classes que de combinaisons de caractères possibles.
Par exemple, un passager "têtu" peut être calme, nerveux, prudent,
agoraphobe ou poli.
La combinaison de 4 types de passager avec 5 caractères permet donc $5 \times 4 = 20$ possibilités.

%Pourquoi cette solution n'est-elle pas satisfaisante ?
Il est à noter que cette solution présente toutefois certains inconvénients car elle nécessite la création
d'une part d'un nombre trop élevé de classes, et d'autre part, elle fait preuve d'une résistance au changement :
si l'on veut créer un nouveau type de comportement à un arrêt, il faut créer
autant de nouvelles classes que de types de Passager (Poli, Fatigue...) à la montée, ce qui
pose un gros problème de duplication de code.\\
En effet, par exemple pour la combinaison de Sportif avec les 
5 actions possibles à l’arrêt, on aura 5 classes concrètes avec à chaque fois le code de \texttt{choixChangerPlace()} de Sportif dupliqué.
\newpage
%\begin{comment}
\subsubsection{Diagramme de classe}
Ci-dessous l'architecture du «framework» correspondant au diagramme de classe après remaniement :

\begin{figure}[h!]
\begin{center}
\includegraphics[scale=0.5]{diag_est_un.eps}
\caption{Diagramme de classe de l'architecture remaniée à l'aide de lien «est-un»}
\end{center}
\end{figure}
%\end{comment}



\subsection*{Avec un lien «a-un »}
L'autre solution consiste à utiliser un lien «a-un» entre la classe abstraite 
PassagerAbstrait et une partie des classes comportenement.\\

Afin d'éviter la duplication de code rencontrée précédemment,  
Une manière de contourner le problème de la duplication est de factoriser le code de \texttt{ChoixPlaceMontee()}
dans les classes de comportement (Calme, Poli,...).
Nous allons donc maintenir le lien «est-un»  pour les quatre types de passager, par contre pour les cinq classes 
représentant les caractères du passager nous choisissons plutôt un lien «a-un».\\
 
Les 2 relation «a-un» et «est-un» possèdent une différence fondamentale. D'une part, le lien  «est-un» traduit la notion d'héritage 
d'autre part, le lien «a-un» reflète la notion d'appartenance.\\
Opter pour la relation «a-un» induit plusieurs conséquences sur les classes impliquées notamment sur les instances :

%Si une classe \texttt{A} posséde un lien «a-un » avec une classe \texttt{B}, quelle conséquence cela a sur les instances ?
Si une classe \texttt{A} possède un lien «a-un» avec une classe \texttt{B}, cela signifie que 
un des attributs de la classe \texttt{A} contient une instance de la classe \texttt{B}.
L'objet de la classe \texttt{B} devra donc :
\begin{itemize}
\item soit être instancié dans le constructeur de la classe \texttt{A}
\item soit passé en argument du constructeur de \texttt{A} et placé dans l'attribut correspondant
\end{itemize}
Il y aura un attribut de type \texttt{B} dans la classe \texttt{A}.




\subsubsection*{Diagramme de classe}
Après ce remaniement, l'architecture du «framework» correspond au diagramme de classe ci-dessous :

\
%\begin{comment}

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.5]{diag_a_un.eps}
\caption{Diagramme de classe de l'architecture remaniée à l'aide de lien «a-un»}
\end{center}
\end{figure}
	
%\end{comment}


Notre architecture sera donc composée des classes Tetu, Fatigué, Repos, Sportif qui hériteront de PassagerAbstrait,
et d'un lien «a-un» reliant les différents comportements à l'arrêt avec PassagerAbstrait ce qui impose la réalisation
d'une variable d'instance pour chaque comportement au sein de PassagerAbstrait. Pour pallier ce problème
% et pour
%que les méthodes utilisant un comportement soient compatibles avec tous les comportements (sans avoir à retoucher
%au code de PassagerAbtrait à chaque ajout de comportement : extensibilité). 
une façon de faire est d'implémenter une interface \textbf{Comportement} contenant la méthode déclarée abstraite
\texttt{choixChangerPlace()}
qui sera implémentée par les différents comportements calme, nerveux, prudent, agoraphobe. Cette interface sera
reliée à PassagerAbstrait par le biais d'un lien «a-un» comme décrit dans le diagramme précédent
Ainsi il suffira de faire une référence à comportement sans être obligé d'écrire pour tous les comportements :
\begin{lstlisting}
public abstract class  PassagerAbstrait extends Passager {  
   private Comportement c;
   ...
}
\end{lstlisting}

On aura donc dans le constructeur de PassagerAbstrait un nouveau paramètre qui est celui de Comportement.
\begin{lstlisting}
  public PassagerAbstrait(String nom, int destination, Comportement c)
\end{lstlisting}

%Combien faut-il construire de classes concrètes ?
Ce remaniement impose la réalisation de 9 classes concrètes : 
Ici les classes Fatigue, Repos, Sportif, Têtu sont concrètes car
elles ne contiennent plus la méthode abstraite \texttt{choixChangerPlace()}. De plus, on a toujours
les cinq classes concrètes qui définissent les cinq caractères différents.\\

Ainsi, le prototype de la méthode \texttt{choixChangerPlace()} est alors modifié.
La méthode \texttt{choixChangerPlace()} n’est pas définie dans une classe qui implémente
Passager, on doit rajouter dans le prototype de cette méthode un objet \texttt{passager}.
On peut déduire un nouveau prototype de la méthode :
\begin{lstlisting}
final choixChangerPlace(Bus b, int Arret, PassagerAbstrait p);
\end{lstlisting}

%Pourquoi n'est-il pas nécessaire de définir un constructeur pour les cinq classes ?
A noter qu'il est nécessaire de définir toutefois un constructeur pour une classe
lorsque celle-ci a des attributs à instancier. Or, les 5 classes liées
au comportement du passager à chaque arrêt contiennent seulement une
méthode, et aucun attribut. On n'a donc pas besoin de définir un
constructeur pour ces classes, le constructeur par défaut suffit donc.\\

%Pourquoi retenir cette solution ?
En définitive, cette solution présente l'avantage d'éviter la duplication de code
ainsi que la possibilité d'ajouter un caractère nécessistant au final la construction d'une seule classe concrète seulement,
et favorisant ainsi la maintenance et la réutilisabilité. Ce qui lui vaut d'être retenue pour la suite.\\


\textbf{Remarque :}\\
La relation d’héritage pour les quatre classes Fatigue, Tetu, Repos, Sportif peut être aussi remplacée par un lien «a-un».\\
Ci-dessous le diagramme représentant l'architecture suivant ce remaniement:

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.5]{Remarque.eps}
\end{center}
\end{figure}

Ce diagramme illustre bien graphiquement la conception orientée aspect mise en avant à savoir la séparation des aspects : comportement 
à la montée et comportement à la descente. On voit clairement les 2 hiérarchies de classe qui représentent ces 2 comportements.
Cependant ce remaniement a été écourté dans la suite pour raison de simplification puiqu'il est possible d'incorporer
l'interface ajoutée à PassagerAbstrait



\subsection*{Boutez vos Neurones.}
Un petit aparté : Supposons maintenant que le langage \textbf{JAVA} autorise l'héritage multiple à l'instar du langage \textbf{C}++.
Nous tentons de remplacer le lien «a-un» précédent par un héritage.\\
ce remaniement est illustré par le diagramme ci-dessous :\\
%Fournir le diagramme de classes.

\begin{figure}[h]
\begin{center}
\includegraphics[scale=0.5]{multiherit.eps}
\caption{Diagramme de classe de l'architecture remaniée à l'aide de l'héritage multiple}
\end{center}
\end{figure}


%Retrouvez-vous le même problème que dans la section 1 ?
A priori, l'héritage multiple permettrait de créer
simplement une classe par type de comportement à l'arrêt (donc 9 classes au total),
il suffirait ensuite de créer un passager qui suivrait 2
types de comportement (l'un à la montée et l'autre à chaque arrêt)
grâce à un héritage double. \\
Par exemple : une formulation possible pour un passager Sportif à caractère Agoraphobe serait :
\begin{lstlisting}
class PassagerSportifAgoraphobe extends PassagerSportif, PassagerAgoraphobe
\end{lstlisting}

Cependant, il est nécessaire de créer les classes correspondant à
toutes les combinaisons possibles de comportements puisque l'héritage est un lien statique.
On se retrouve
alors avec les 20 classes de la section 1 en plus des 9 classes par défaut, 
donc un total de $20 + 9 = 29$.\\
cependant cette solution présente un net avantage par rapport à la 
première à savoir 
contrairement au début, il n'y a plus duplication de code, si un comportement 
ou caractère est modifié tous les passagers subiront automatiquement les changements
grâce à l'héritage

\subsection*{En conclusion :}
%Donner les deux différences entre un lien «est-un » et un lien «a-un »

Le lien «est-un» définit une relation d'héritage entre 2 classes ainsi
une classe \texttt{B} a un lien «est-un» avec une classe \texttt{A} signifie 
que \texttt{B} hérite de \texttt{A}
alors que le lien «a-un» entre la
classe \texttt{A} et \texttt{B} correspond à un attribut de type \texttt{B} dans la classe \texttt{A}.\\
Ces 2 liens se traduise en Java par exemple de la manière suivante :\\
\textbf{Lien Est-un}\\
\begin{lstlisting}
public class A extends B { ...
	A a = new B();
}
\end{lstlisting}
\textbf{Lien A-un} :
\begin{lstlisting}
public class A {
  private B b;  //
  ...
}
\end{lstlisting}

Ceci a pour conséquence le fait que pour instancier un type de passager, il faut
instancier au minimum deux classes pour un lien «a-un », contre un seul
dans le cas d'un lien «a-un ». 
De plus, un lien «est-un » est un lien statique,
il se fait à la compilation, tandis qu'un lien «a-un » est un lien
dynamique, qui se forme à l'exécution\\
On constate donc que les deux différences entre un lien «est-un » et un lien «a-un »
sont d'une part la nécéssité pour un lien «a-un » d'instancier au minimum 
deux objets pour instancier un type de passager, contre un seul pour un
lien «est-un » . Et d'autre part le fait qu'un lien «est-un » soit un lien statique,
formé à la compilation, tandis qu'un lien «a-un » est un lien dynamique et se
forme l'exécution.




\section*{Onzième itération : Réalisation du lien «a-un »}
Avec le lien «a-un », l’instanciation d’une des quatre classes Fatigue, Tetu, Repos, Sportif 
nécessite obligatoirement une instance d’une des cinq classes Calme, Nerveux, Prudent, Agoraphobe, Poli.\\
Nous allons discuter les choix qui s'offrent à nous concernant l'instanciation des 5 classes\\

\subsection*{Question d'instanciation}
\subsubsection*{Première solution}
Une première solution est d'envisager que l’instanciation est faite par les sous-classes de PassagerAbstrait.
Deux possibilités sont envisageables :
Chaque sous-classe effectue l’instanciation dans son constructeur.\\
%ANALYSE
par exemple pour un passager sportif agoraphobe on aura :
\begin{lstlisting}
public PassagerSportif() {
  comportement = new Agoraphobe(); 
  ...
}
\end{lstlisting}

\textbf{NOTE :}
La classe Agoraphobe fera appel à la methode \verb+super()+ pour instancier PassagerAbstrait car 
instancer une classe «grand-mère» (classe mère à é niveau) n'est pas possible

L'inconvénient de cette méthode réside dans le fait qu'elle impose la création de classe concrète pour chaque 
combinaison et donc se traduit par un nombre élevé de classe à instancier puisque il nous faudra dans notre
cas instancier 20 classes pour manipuler toutes les combinaisons possibles.
Une seconde et meilleure façon d'aborder à priori cette méthode est de faire passer une chaîne de
caractère dans les constructeurs des 4 classe-filles Tetu, Fatigue, Repos et Sportif 
et d'instancier le bon comportement à l'aide de branchements conditionnels :
pour l'exemple de SportifAgoraphobe nous aurons :

\begin{lstlisting}
public PassagerSportif(String comport, String nom, int destination) {
  Comportement c;
  if (comport.equals("Agoraphobe")){
    c = new Agoraphobe(nom, Destination);
  }
  else if ...
}
\end{lstlisting}
L'avantage de cette solution nous permet de ne pas instancier toutes les 20 sous-classes. 
Cependant, si nous décidions de rajouter par exemple un nouveau comportement, il faudra 
modifier le code des constructueurs de toutes les classes Tetu, Fatigue, Repos et Sportif
en rajoutant un branchement supplémentaire. La réutilisabilité des constructeurs en est affectée

\begin{lstlisting}
public PassagerSportif(String nom, int destination) {
  Comportement c  = new Agoraphobe(nom, destination); 
  ...
}
\end{lstlisting}

\subsubsection*{Deuxième solution}
Une seconde solution est de considérer que l’instanciation n’est pas faite par les sous-classes. 
L’instance de comportement est passée en paramètre du constructeur des 4 classe-filles. 
Dès lors, l’instanciation est faite par le client dans le programme principale (test de recette) 
ce qui stipule de déclarer les classes de comportement (Calme, Poli...) en \verb+Public+
altérant le masquage de la réalisation. De plus, rien n'empêche le client
de mettre au point n'importe quelle combinaison, y compris des
combinaisons incohérentes.\\
Dans cette technique, c'est l'utilisateur qui choisit quel comportement il combine 
avec le type de passager. Cela évite de construire toutes les classes passager et il 
pourra plus facilement ajouter de nouveaux caractères. Puisque les comportements 
et caractères sont accessibles depuis l'extérieur, il faut qu'elles soit publiques
sinon elle seraient invisibles à l'utilisateur.

\begin{lstlisting}
public Passagerfatigue(Comportement c, String nom, int destination) {
  super(nom, destination, c);                                
  ...
}
\end{lstlisting}

Une manière de contourner le problème est de léguer l'instanciation des objets à une classe de type «fabrique ».
Le client fera appel à cette classe ce qui permet de cacher la réalisation.\\
Un exemple de fabrique :
\begin{lstlisting}
comportement FaireCalme() {
  Comportement c = new calme();
  return c;                              
}
\end{lstlisting}


\subsection*{Choix des méthodes pour les branches du projet}
Notre projet est subdivisé en deux branches qui
se différencient par la manière dont sont instanciés les passagers.
Dans un cas l'instanciation est faite directement par le client, il a
donc une liberté importante sur l'instanciation, c'est pourquoi la
deuxième solution conviendrait mieux à cette branche, le client garde
alors sa liberté d'action.\\ Le fait que l'instanciation se fasse
grâce à une fabrique dans la deuxième branche convient parfaitement à
une vision plus restrictive du cadriciel (\emph{framework}). En effet il était déjà
possible d'effectuer une restriction en n'implémentant pas les méthodes de fabrique
\texttt{fairePassager}.



\subsection*{Boutez vos Neurones}
On pourrait envisager de stocker un bus et un passager associé à un
caractère sous la forme d'attributs des classes Calme, Nerveux,
Prudent, Agoraphobe, Poli. Cependant cette solution nous empêche de
faire de ces classes des objets constants ce qui pourrait être une
évolution intéressante car elle réduirait le nombre d'instances de ces
classes en les limitant à un.




\section*{Conclusion}
Finalement nous avons à notre disposition deux branches d'un projet
dont l'approche est différente. La première laisse à l'utilisateur la
responsabilité de l'instanciation, lui donnant ainsi
l'opportunité de réaliser toutes les combinaisons possibles. L'autre
restreint le nombre de combinaisons réalisables, et permet de gérer les
cas incohérents. Une évolution intéressante de notre projet consisterait
à reprendre
les mécanismes d'exception vus au cours afin d'empêcher la réalisation de
ces comportements incohérents et de compléter votre code.



\end{document}
